Typical EMR/EHR software applications produced for use by front-line healthcare workers follow a flow-based model. That is, the healthcare provider is required to navigate through a series of windows according to a pre-established flow and then enter data related to a patient encounter at the appropriate window. Because the data is entered at a window that is part of a pre-established flow, the EMR/EHR application knows exactly what type of data to expect at each data entry point. For example, if a healthcare worker navigates to a diagnosis window and checks a box labeled “sprained ankle,” the EMR/EHR application is coded to identify the input data as a sprained ankle. A drawback to applying flow-based software applications to the healthcare industry is that the flow produced by the software developer and coded into the application may not match the actual work flow of a healthcare worker.
Electronic writing systems have been developed to translate a user writing on a paper form to electronic data. Translating user writing on a paper form to electronic data can help free a healthcare worker from the requirements of rigid flow-based EMR/EHR applications. Typical electronic writing systems track the pen strokes of a user writing on a form and generate a data set that represents the user's pen strokes. The pen stroke data set is then used to create an electronic image of the marked up form. The electronic image can be viewed on a remote computer to perform various tasks that need to be completed subsequent to a patient encounter (e.g., patient/insurance billing, case management, order fulfillment, etc.).
While creating an electronic image of a marked up form on a remote computer allows subsequent electronic access to the marked up forms, to glean useful data from the user writing on the form, a person viewing the electronic image must manually convert the user writings to useable data, by for example, keying in data from check boxes. Alternatively, useful data can be gleaned from the pen stroke data set by programming the EMR/EHR application to relate pen stroke data directly to a software routine or action. For example, a software developer must hardcode that a check at the coordinates of a box labeled “sprained ankle” translates to the diagnosis of a sprained ankle. This process is very inefficient for a software developer because it requires the developer to have specific knowledge of the layout of every information field on every form that is to be used with the EMR/EHR application. Further, even if the developer does attempt to hardcode every field of every form to a corresponding routine or action, it is often desirable or necessary to change the layout of a form to accommodate new and/or different information. If an EMR/EHR application is directly dependent on the layout of a form, the EMR/EHR application must be reprogrammed to reflect each subsequent layout change.
Further, different electronic writing systems exist which use different techniques to translate user writings to a pen stroke data set. Consequently, the same information on a form may result in a different pen stroke data set depending on which electronic writing system is used to track the pen strokes and therefore an EMR/EHR application must be coded to deal with all the possible pen stroke data sets for each electronic writing system that is to be supported by the EMR/EHR application.